Many commercial databases and applications store their data in files. The file systems they use are unusual because they typically contain relatively small numbers of large files with long lifetimes. A database may be divided into one or more logical storage units called table spaces, and a table space may contain logical entities, such as tables and indexes. A table space may be stored in one or more physical data files. Thus, a database may store data logically in table spaces and physically in data files associated with a corresponding table space.
Table spaces may further be divided into logical units referred to as segments, which may be divided into database extents. Database extents may include a collection of continuous blocks in a data file. For tables, storage space may be allocated on demand as new rows are inserted into a table, and a database may spread tables across one or more data files by allocating database extents from different data files each time rows are inserted into a table. Thus, a data file may include database extents of multiple tables, and a table may include database extents from multiple data files. These data files are typically large in size, and portions of the files are randomly accessed. Accordingly, some portions of a database file may be accessed infrequently, remaining untouched or cold for extended periods of time (or during the entire life cycle of the database file).
In current storage management and file relocation solutions, a whole database file may be relocated based on the I/O activity of the entire file. As a result, several table database extents belonging to multiple tables may be relocated to the same storage location (e.g., a lower quality of service storage location), even if some of the database extents are accessed frequently and others are accessed infrequently. Such relocation may adversely impact not only performance for one or more tables of a database, but also the optimization of storage utilization.